In the manufacture of integrated circuits, there is a requirement of not just designing the integrated circuit and manufacturing it, but also testing it. The test software for an integrated circuit is desirably available as efficiently as possible. The resources for developing the test software are a limited quantity. Further, the test software should be verified and completely debugged prior to the first silicon of the integrated circuit being available.
Several problems relating to providing the test software make it difficult to achieve the desired timeliness. One is that the techniques used in the first testing of the design are simply for verifying that the design is valid. This verification software is not transferable immediately to the tester. After the design of the integrated circuit has been verified as providing the desired operation, the development of the test software can begin. The process of developing the test software can take months. It may take longer than the time for the first silicon to appear, which is clearly undesirable.
A test pattern generation flow 10 of the prior art, which exhibits these problems, is shown in FIG. 1. A test pattern generation flow 10 comprises a stimulus 12, a device under test (DUT) 14, a test bench 16, a raw dump 18, a raw dump 20, manual processing 22, manual processing 24, tester converter 26, a tester 28, a virtual test simulation 30, and a fault simulation 32. In typical operation DUT 14 is a completed design that is tested by a stimulus 12 using test bench 16. DUT 14 is a device model of the designed integrated circuit, which is in a format that allows it to be verified and simulated.
Stimulus 12 works directly with DUT 14 and also operates on DUT 14 through test bench 16. During this time period, stimulus 12 is testing DUT 14 with respect to a specification that DUT 14 used in its design. The specification may be silent on some issues, may be unclear, or may be untestable. In such case, stimulus 12 may be testing for things that DUT 14 either does not have, or was designed with a different function in mind. These issues are worked out and eventually stimulus 12 and DUT 14 are harmonized.
After agreement has been reached so that stimulus 12 and DUT 14 are harmonized, the design of the test software for testing the ultimate integrated circuit that would be made using the design for DUT 14 is begun. This begins with a raw dump of the data that was used in the development of DUT and in the testing so that test bench 16 and DUT 14 provide raw dump 18 and raw dump 20. Raw dump 18 undergoes manual setup for the purpose of generating the test software. The manual setup that occurs at this step can be very difficult and tedious because the data itself is not complete or conveniently formatted. The data is sufficient, perhaps, for calculations to be made and conclusions to be drawn so that things such as signal direction, signal timing, and whether the signal should be masked can be calculated or derived by reference to the DUT. The need to refer back to the DUT itself may be very difficult and time consuming and may result in errors. This may require communication back to the designers of the DUT 14. Those designers may be on other projects or perhaps not even available. This process alone commonly can often take several weeks.
After this step is complete, tester converter 26 converts this data to a form that is usable by the tester 28. This conversion has several characteristics. One of the most significant of these characteristics is cyclization. The converted data is also used to enable a virtual test simulation 30. Virtual test simulation 30 performs a test on DUT 14 to verify that tester software provided to tester 28 is correct.
Raw dump 20 is substantially the same information as raw dump 18 but is typically in a different format. Manual setup 24 is performed on raw dump 20 to produce a fault simulation 32. Fault simulation 32 is used to grade the performance of the tester software. Thus, fault simulation 32 is operating on substantially the same data provided by test bench 16 and DUT 14 as raw dump 18 but there is a substantial processing difference that occurs. Being in substantially different format, if mistakes are made in either fault simulation 32 or the test software, then it is difficult to correlate the mistake in one to the similar location in the other. Manual processing 24 takes about the same amount of time as manual processing 22 and the debug is also difficult.
Thus, it is seen there is a need for a process for developing test software that does not require so much time, so much manual processing, and so much difficulty in debugging.